Many types of digital computer system utilize code transformation/translation or emulation to implement software-based functionality. Generally, translation and emulation both involve examining a program of software instructions and performing the functions and actions dictated by the software instructions, even though the instructions are not “native” to the computer system. For example, in an emulated architecture, the non-native (or guest) instructions may be mapped into a form of native instructions, which are designed to execute on the hardware of the computer system.
As described in detail in application Ser. No. 13/359,767, guest instruction blocks are converted or mapped into native conversion blocks in an emulated architecture. As described in application Ser. No. 13/359,767, guest instructions in an emulated architecture can be from a number of different guest instruction architectures (e.g., Java, x86, MIPS etc.) and multiple guest instruction blocks can be converted into one or more corresponding native conversion blocks. This conversion occurs on a per instruction basis. For example, a block of guest code may be converted into several corresponding instruction sequences of native code.
Further, as described in application Ser. No. 13/359,767, a structure such as a Conversion Lookaside Buffer (CLB) is commonly used to provide a mapping between the guest addresses and native addresses in emulated architectures. A conversion look aside buffer is typically used to cache the address mappings between guest and native blocks; such that the most frequently encountered native conversion blocks are accessed through low latency availability to the processor. Using a CLB accelerates the process of translating guest instructions from a guest instruction architecture into native instructions of a native instruction architecture for execution on a native processor. The guest instructions are rapidly converted into native instructions using the CLB and pipelined to the native processor hardware for rapid execution.
In certain instances, a CLB may get temporarily flooded with too many entries because of function calls to the same function in the guest space. A function call comprises both a call to the function from within an instruction sequence and a return back to the instruction sequence after the function has executed. For each return, following a call, (hereinafter referred to as “function returns”) from a function in guest space then, a new corresponding instruction sequence is typically started in native space from the return address of the function. Accordingly, a new mapping would have to be created in the CLB for each such return. Because a function may be called from multiple places from within a block of guest code, it results in several guest-to-native mappings for the function in the CLB. This leads to a temporary flooding of the CLB, which is a precious resource in the processor pipeline and is a very inefficient use of the CLB structure.